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The Purpose and Content of BONOPORM alias SUTHERN COMFORT 


Introduction 


Bobrow, Sutherland and Licklider constitute a committee of the 
ARPA network circle. .The purpose of the committee is in the 
general vicinity of x, where x is to do something about protocol, 
formats, conventions, or language for messages transmitted 
through oho ARPA network, The purpose of this memorandum is to 
clarify the purpose of the committee and to relate the general 
nature of the expected product of the committee to the context of 
the ARPA network. This memorandum will not describe the expected 
product. 

The expected product of the committee is a language for defining 
message forms of formats. As suggested opposite "Subject," I am 
proposing to call the language either "Bobrow Normal Form" or 
"Sutherland Network Communication Format." "Bonoform" has the 
advantage of compactness and will be used in the remainder of 
this memorandum. 

Context and Purpose ’ 

The ARPA network circle meeting of May 18, 1967, decided, among 
other things, to adopt the Interface Message Processor concept 
and to use ASCII code and its rules without deviation in the 
interior communication language of the network. Each IMP, will be 
either (preferably) a small computer or (acceptably) a functional 
part of a large one. In the 'former case, the interface between 
the local part of the node and the part of the node dominated 
by network-wide conventions will be a software-software inter¬ 
face Inside the IMP. In the latter case, the part of the large 
computer dominated by network-wide conventions will perforce look 
to the communication lines' and to the rest of the node.- exactly 
like an IMP. The interior communication language, which I shall 
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abbreviate INTERCOM (or Intercom, since - perhaps because of 
i their relative unavailability - I prefer lower-case letters), is 
the language that flows through the communication lines and 
switches, and within the part of the IMPs that are dominated by 
network-wide conventions. The meeting of May 11 made progress 
toward the specification of format for Intercom messages. However, 
only the headers and trailers of such messages are strongly con¬ 
strained by the specifications. All that is said about the bodies 
of such messages is that they shall conform with the ASCII rules. 
Insofar as the body messages are made up of characters, the 
characters must be ASCII characters of seven identifying bits and 
one parity bit. Insofar as the body messages contain pure binary 
information, it must be 6-bit binary; the other two bits are pre¬ 
empted by ASCII constraints. 

As the primitive mind works, the next question concerns further 
specification of the language of the body (l.e., not Intercom 
header or trailer) messages. However, the minds ef two-thirds of 
the present committee are not primitive. The next question there¬ 
fore concerns not the body language itself but a language for 
describing the formats of body messages. This message-format¬ 
describing language is what I am calling Bonoform. 

Chalmers Sherwin has been (and is) advocating a system for handling 
the problem of formats for messages of the kind with which we 
are concerned. Two elements of his system are a standards office 
end a standard header. Anyone can invent or define a format, send 
it to the standards office, and (if it meets the simple rules) have 
it registered, assigned a format number, and listed. Then, when 
he sends a message, he need only put the format number in its 
proper place in the standard header. In the body that follows 
the header, he transmits whatever the format calls for, and his 
recipient, who presumably has a copy of the format description, 
decodes, or interprets the message accordingly. 

Instead of relying on the'standards office, of course, one could 


:- 2 - 



send the format description as a message, providing the format 
of the format description were agreed upon by both sender and 
receiver. It is precisely the purpose of Bonoform to define the 
format of format description and other parts of the language 
of message descriptions. 

Schedule of Work 


At a committee meeting yesterday, Che general character of 
Bonoform was agreed upon. It will be somewhat like Backus normal 
Form. It will provide for assignments of character (l.e., charac¬ 
terization) and for assignments of value. All variables that may 
be assigned values will be global. Characterization may be 
hierarchical. That is, a format may be defined by a statement 
containing terms that are defined (i.e., formats that are 
characterized) in other statements. And so on. But the language 
is intended to be very simple. It will not be a programming 
language. 

Bobrow and Sutherland see problems arising, problems familiar 
to them in other experiences in the field of formal languages. 
Bobrow is going to write/up a preliminary description of the 
language and a brief discussion of the problems. 

Then there will be another committee meeting. 

The target date for unveiling of the language is July 1, 1967. 
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Quoted Strings 

There are two classes of quoted strings - character strings 
and numeric: otrlngB. When uood in describing messages, character 
strings are surrounded by double quotes (") e.g. "AB CDE". 

Numeric strings are surrounded by "single" quotes (') and 
followed by a base indication, i.e. B=Binary, Q=0ctal, 

D*Decimal, H*Hexidecimal. 

e.g. '1101 1 B or '377'Q etc. 

Reserved Words 


BIT 

A Bit 

CHAR 

Any Character 

SQ 

A single quote 

DQ 

A double quote 

FP 

Floating point number 

etc, 

As needed 

Characterization 

Statements 


A characterization statement characterizes a message form, 
similar to a definition statement in BNF. The left side 
is a single name (a message or submessage name) followed by 
an equals sign (=) followed by submessages separated by +.for 
concatenations. Alternatives are indicated separating sets of 



